Not Applicable
Not Applicable
Not Applicable
The present invention generally relates to public switched telephone networks (PSTN""s)/voice-over-IP telephony and particularly to the application of the extension of scripts to interact with PSTN and IP telephones within the context of the same services. More specifically, the present invention relates generally to a Virtual Automatic Call Director environment with integrated Voice Response Unit (VRU) and Virtual Automatic Call Distributor (VACD) that permits a complete call flow to be executed in a single process.
IP-based agent technology is evolving for IP call centers. The major problems with legacy call centers have been proprietary interfaces for service creation within switches that are complex to change. Most switch vendors control what information is accessible and makes development of new services very difficult. The invention enables a virtual Automatic Call Director (ACD) environment with integrated Voice Response Unit (VRU) and Virtual Automatic Call Distributor (VACD) to enable a programmable interface with a common script logic so that the complete call flow can be execute in a single process.
Referencing FIG. 1, the present state of the art includes telephone equipment (101), public switched telephone networks (102), and public branch exchanges (103). Remaining elements in this figure may be incorporated using the teachings of the present invention to provide features not present in the prior art.
Accordingly, the objects of the present invention are (among others) to circumvent the deficiencies in the prior art and affect the following objectives:
1. To provide a common script logic to enable complete call flow to be executed in a single process.
2. To permit extensions to existing call functions enabled at an API interface level that is available to application programmers.
While these objectives should not be understood to limit the teachings of the present invention, in general these objectives are achieved by the disclosed invention that is discussed in the following sections.
IP based agent technology is evolving for IP call centers. The major problems with legacy call centers have been proprietary interfaces for service creation within switches that are complex to change. Most switch vendors control what information is accessible and makes development of new services very difficult.
Referencing FIG. 2, the present invention (200) enables a virtual ACD environment (203) with integrated Voice response unit (VRU) and Virtual Automatic Call Distributor (VACD) to have a programmable interface with a common script logic so that the complete call flow can be execute in a single process.
This section describes the work flow of the agent application using the Java Phone toolkit (208) and the work flow of the telephony application (i.e. the State Table (201, 400)) using the Call Director (202). Together with the detailed API interface (300) it provides an insight on how the Gateway operates in a call center. The description includes all the messages between the application (the State Table (201, 400), the Call Director Custom service, the VACD, the Java Phone toolkit (208) DACP interface and the Java Phone toolkit API. The goal of this discussion is to provide exemplary teaching and directions on how to use the APIs of each component from the xe2x80x98call point of viewxe2x80x99.
Gateway Initiation
When DT starts both VOD (Voice over Data) CS and CD CS are initiated using the VOD_Init( ) and CD_Init functions. The VACD component is activated using the AIX Inittab and is assumed to be active at init time, the CD CS would establish a connection with the VACD at this stage.
Once the Call Director Custom Server has been started the call center is ready to start working.
Call Center Application Startup
The Java Phone toolkit (208) is activated by the Call Center application. The toolkit is activated with the socket interface option. The InitPhone message is sent at the Call Center application init stage and this action starts an H.323 (206) call to the Gateway (without a phone number). Once the call is established a short voice message would be played to the operator.
Agent Logon
Once the application is running the agent must logon to the call center system. The AgentLogon message propagates (with different formats) from the application through the toolkit through the CD CS to the VACD. The message includes userid, IP address, and password. A response is being sent back on the same route (an acknowledge is not implemented at this stage since we assume fast response). This information is also propagated by the VACD to the Call Router. A similar process is followed for AgentLogoff.
Agent Ready
Once logged on the application should send the AgentReady message. The AgentReady message propagates (with different formats) from the application through the toolkit through the CD CS to the VACD. A response is being sent back on the same route. At this stage the agent is ready to accept calls. This information is also propagated by the VACD to the Call Router.
From now on an AgentNotReady message can be sent on the same route with a similar response. This would direct the VACD to stop sending calls to the agent. A similar process is followed for AgentNotReady.
Application State Table
As generally illustrated in FIG. 1, the Network Call Center (NCC) with Call Director (100) system will now be described in detail. The overall operation of the Call Flow through the Call Director is illustrated in FIG. 1 with exemplary data flow illustrated in FIG. 2. The call flows will focus on the use of the Call Director and VOD (IP Telephony) CS. other components such as the Call Router (ICR) (104) CS and others are described elsewhere. The Application State Table is invoked ONLY when a call is accepted by the Call Director (110) and a caller (101) is connected to the PSTN (102) side. The PSTN interface can be to any switch or a PBX (103) that can provide ANI/DNIS information as well as call transfer capability relative to the calls.
The ICR is part of the IBM callpath product. It is intelligent call routing and the call is routed based on called and calling number information of a call. The agent selection and load balancing is done based on this and more information collected from caller. More information on ICR is available in the document entitled xe2x80x9cCall Path programmers Users Guide Ver 6, Rel 2xe2x80x9d, June 1999 which is available at online URL
(www-4.ibm.com/software/speech/enterprise/universalaccessxe2x80x941xe2x80x941.html.).
Each call that needs service from the Call Center opens a call_id using the CD_NewCallID (321) function. Information gathered from the user such as skills is passed to the CD CS using the CD_SaveCallInfo (322) function. The Call Director (110) passes this information to the Call Router (ICR) (104) to get the destination for Agent Pool or skill that needs to be used.
Using the destination information, the CD_GetAgent (323) function is invoked. This function will cause the CD to spawn a request to the VACD (114) to get an agent from the pool. The VACD (114) will be provided with all the call info saved prior to this call. Any information saved after this function has been called will not affect the pending request. If an agent is instantly ready for operation the VACD (114) will return with a valid IP address of the Agent and a return code of CD_OK (=0). If there is no agent ready immediately, the API will return CD_PENDING (=1) and a request ID that will be a handle to the pending request. When the ST will want to know when the agent is ready for this pending request, it should issue a CD_NotifyEvent (324) on the relevant call_id and will get an appropriate event when the agent will be ready. The ST is able to issue the CD_AbortRequest (329) with the request ID handle to abort the request.
Note that the CD_NotifyEvent (324) function should be called in any case for each call_id opened. This is the route in which all events related to a call, such as agent""s messages/requests (such as Call Transfer, Disconnect, etc.) are being transferred to the ST. Once an event notification has been received the CD_GetEventInfo (326) function is used in order to get the information related to the last event.
Also note when the ST is not working under an active DT channel (such as in a case when the call was originated from an H.323 (206) entity) the ST must NOT issue CD_NotifyEvent (324), because the event mechanism of the IBM Direct/Talk 6000(trademark) line of products will not work. In this case the ST can simply poll for incoming events using the same CD_GetEventInfo (326), where the event type of zero will indicate no pending events.
Once an agent has been received use the regular VOD CS API to open a network call to the agent. Note that since the connection is already on the VOD CS, it would not start a new H.323 call, it would only respond back with the already opened IP handle.
A CD_CallAvailable (325) function is used to notify the agent about the new call once it is established. This would propagate from the CD CS through the DACP and to the toolkit. The Call Center application is getting a CallCreated message. At this stage the agent and the caller can talk.
The ST is now waiting for event from the call. Several scenarios can occur now, each one of them are described separately:
Caller Hangs Up
A notification is being received in such a case to the ST using the regular Direct Talk mechanism. The VOD_Disconnect function is used to disconnect any streaming voice to the agent (if such stream exists at that time) and then send CD_CallComplete (327) to notify the toolkit (through the DACP) that the call has been disconnected. At that point the Call Center application receives a CallRemoved message. After issuing CD_CallComplete (327) the CD_ReturnAgent (328) function is used to notify the VACD (114) that this agent is free again to accept new calls.
The last thing the ST should do is release the call_id by calling CD_EndCall (320). At this stage the call has ended and the ST is can terminate.
Note that the VOD_Close() is used ONLY in case the ST received a hangup or an Error event from the IP handle. In normal operation the ST should leave the H.323 connection open.
The following are additional actions that the call director state table has to act on during an active call:
Agent requests conference with Supervisor
Agent requests transfer to another agent
Agent releases call to automated VRU